Size Change: +4 B (0%)

Total Size: 1.77 MB

_{compressed-size-action}

@WordPress/gutenberg-design for now I've only removed style overrides. Here's the inserter > patterns Tabs instance.

Before (with overrides):

After (without overrides):

The main differences I spot in the previous style overrides vs default Tabs styles:

• Lighter font weight
• Light blue indicator
• Active tab has text and svg fill color set to blue (vs. no difference)
• Smaller tab padding resulting in shorter/more compact tabs

For reference, here's the preferences dialog tabs, which already don't have any style overrides:

These are the only two instances of Tabs at the moment in Gutenberg. Ideally, we'd find styles that work in both cases. If necessary, we can consider introducing some sort of variant, but let's try to keep that at a minimum and find something that we feel good about regarding future usage of the component, to prevent more style overrides in the future.

Please leave some feedback, happy to implement any ideas so we can test them!

+100 to removing the overrides.

That said, I think the appearance in the Editor is the direction we want to go in. So would it make sense to update the component first, then remove the overrides after? That way there should be minimal visual disruption.

One detail we need to consider is that the color change (gray or blue) is of inadequate contrast to meet requirements, so we need another way to communicate which tab is active. We could address this while updating the component. A good place to start could be making the active tab font weight slightly heavier.

What do you think?

So would it make sense to update the component first, then remove the overrides after? That way there should be minimal visual disruption.

Well, the thing is we only have two instances of vertical tabs, so what you're proposing doesn't make much sense purely in terms of the sequence of steps hehe. If, instead of removing overrides, I update the base component, then the preferences tabs will be affected, so either way there'd be visual disruption.

Here's how I think this PR should evolve:

1. Remove overrides (done).
2. Update the Tabs component to look how we want it to look in both instances (inserter and preferences).
3. Test and iterate until we feel good about it.
4. Merge and ship it.

I hope that makes sense to you?

Regarding your suggestion that the styles of the inserter tabs are closer to what we want, that makes sense to me. I'll tweak the base component, so both instances will look closer to it.

In parallel, I will also apply your suggestion about the active tab styles. Then, we can take it from there.

Sound good? :)

@DaniGuardiola In my experience we don't tend to update multiple things in a single PR like you're suggesting, hence my idea to update the component first. That said, it does make sense to me in this context, providing other folks in the @WordPress/gutenberg-components team agree.

@jameskoster

A good place to start could be making the active tab font weight slightly heavier.

Currently, the weight for tabs is 500. In the inserter, it was overridden to 400.

What if we:

• Set the default weight to 400 (like in the inserter).
• Make the active tab 500.

This is how that looks like in inserter and preferences:

I also tried making the active tab have the theme accent color (blue in this case) like the inserter style overrides did. For reference, this is the same color that tabs have when hovered. Here's how it looks like:

I quite like this with the light gray indicator. However, it might still not be enough for colorblind or low-vision people.

Here, I tried making the active tab have a weight of 600 (on top of all previous changes):

And here's with 700:

I personally feel much more comfortable shipping this with the increased font weights. Thoughts?

By the way, the font weight and text color changes also affect horizontal tabs, as you can see in the videos. That said, we could always special-case it to vertical tabs if we don't want that to happen. Maybe worth doing it in both for consistency though, it communicates more clearly that both (vertical and horizontal) are the same component rather than different ones.

I reckon we should only apply the weight change to vertical tabs, if possible. Horizontal tabs are fine by virtue of the 'active' shape having enough contrast.

In #64340 (comment) we're leaning towards 500 where additional weight is required, so perhaps we try that here, with inactive tabs using 400?

Here's a visual for the different states, hopefully this communicates things better than words :D

Figma link.

@jameskoster

In #64340 (comment) we're leaning towards 500 where additional weight is required, so perhaps we try that here, with inactive tabs using 400?

You can see this in my previous comment, it's the first example. Qs:

1. From the screenshot of the Figma design, I infer that we also want the text color to be the theme accent color as I suggested in my last comment, correct?
2. And we'll want the light blue (theme accent color at 4% opacity) indicator color too, instead of the current gray one?
3. I will insist on the point that 500 is not enough weight in my opinion to indicate the active tab. The active text color (as mentioned in point 1 of this list) does help a bit, but it doesn't seem like enough in this context. I got good vision, and still struggle a bit to clearly tell those apart. See my last comment for examples at higher weights.

For now, I'm gonna assume that the answer is yes to points 1 and 2 and push those changes in this PR.

FYI, there's a problem that #64371 fixes that makes the indicator not show up in the inserter, in case you wanted to try it locally. I'm performing a quick hack to get these screenshots and videos for now, but you won't be able to test it locally for now. Hopefully we'll be able to merge that soon though. Let me know if you want me to record or capture something in the meantime.

@jameskoster

I applied all changes, including the 400/500 weight change, and here's how that looks like currently. 500 (semibold) still seems too low for me, especially with the light blue indicator which looks even dimmer than the previous gray one to me.

You may be right about the weight, but the more we increase it the more legibility in certain languages decreases. I think we should proceed with 500 for now, as it is aligned with #64340 (comment) and also because it is objectively an improvement on trunk.

We can gather feedback and open a dedicated issue for this detail. There are other options to explore like adding a shape to the active tab:

It's not something that needs to block the other enhancements here, and needs broader visibility to determine the best direction.

One small detail; the radius on the active tab should be radius-small.

@jameskoster various thoughts:

• Font weight: alright, sounds good.
• Radius: we could add it, but FYI due to constraints of the web platform, adding a radius would force us to downgrade to a different animation technique for the indicator that would result in slightly worse performance. Not the end of the world, but important to consider.
• The proposed border design has a curvature that, as far as I know, is not doable in CSS. The best that can be done (without some ugly convoluted tricks that would probably have a negative effect on perf and bundle size) is something like the image below. I strongly recommend that we don't try to implement that non-standard border curvature.

• Current focus-visible style looks like the image below. This is the same style as in horizontal tabs. Is this okay? I personally think it's fine and better since it's consistent with the other orientation. Also less divergent code (for horizontal vs vertical).

• Are we okay with the size as it currently is? The most obvious change in the patterns inserter after the merges would currently be that those tabs are significantly taller now and less dense. I think it's fine, personally, but something to discuss anyway.

@DaniGuardiola sorry, the border treatment wasn't a proposal; just an example of something we could try instead of changing the font weight. It's best to explore this in detail in a dedicated issue.

slightly worse performance

How bad are we talking? The majority of UI components have rounded corners, it should be a shame to introduce an inconsistency here.

sorry, the border treatment wasn't a proposal; just an example of something we could try instead of changing the font weight. It's best to explore this in detail in a dedicated issue

Sure, though I'm a bit worried that we'll make tabs worse if we merge this PR with a design that's considered "incomplete". The goal of this PR was to iterate on a unified design in the first place. I'm happy to split into multiple ones, but let's be careful not to make it worse before making it better.

How bad are we talking?

Not that much. We just can't take advantage of transform anymore. It might become noticeable in lower-end mobile devices, mostly.

Would you mind responding to the rest of the items in my last comment? I want to keep the PR moving forward :D

Sure, though I'm a bit worried that we'll make tabs worse if we merge this PR with a design that's considered "incomplete".

I don't think so because we're objectively improving compared with trunk in terms of a11y.

This is the same style as in horizontal tabs. Is this okay?

Agree with you that this is okay for now.

Are we okay with the size as it currently is?

Ideally the vertical tabs are 40px tall. This aligns with the general size convention we have for interactive elements (24/32/40).

I don't think so because we're objectively improving compared with trunk in terms of a11y.

I find the light blue background harder to see than the previous gray one. This only affects the preferences tabs FWIW. That said, no strong feelings on my side, as long as we don't forget to improve a11y in a follow-up.

Agree with you that this is okay for now.

Cool!

Ideally the vertical tabs are 40px tall.

Okay, right now they are 48px tall. I'll change this to 40px. For reference, this is the original size of the patterns/media tabs, ergo after this PR merges, the size change will only be noticeable on the preferences tabs.

Flaky tests detected in 07069c8.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11183992724
📝 Reported issues:

• [Flaky Test] Overlay menu interactions in Safari (@webkit) #55816 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

I'm not seeing any issues in testing. I think I did see the flashing focus ring Marco mentioned but not now (since ece5efc).

@stokesman yes, the flashing has indeed been fixed 👍

FYI, #65878 should be backported before this one to avoid nasty conflicts :)

Hey folks, this is labeled as an enhancement, but it fixes a regression in 6.7. Therefore, it's unclear to me if this should be included in 6.7 itself. Thoughts?

Hey folks, this is labeled as an enhancement, but it fixes a regression in 6.7. Therefore, it's unclear to me if this should be included in 6.7 itself. Thoughts?

I thought the regression was introduced in #64371, which I thought was not part of 6.7 either — that's why this is marked only to be backported to Gutenberg RC. But if the fix is needed in 6.7, we should definitely backport it (together with #65837 and any dependant PR)

I thought the regression was introduced in #64371, which I thought was not part of 6.7 either — that's why this is marked only to be backported to Gutenberg RC. But if the fix is needed in 6.7, we should definitely backport it (together with #65837 and any dependant PR)

You are correct, I just confirmed. I'll remove #65837 from the 6.7 board. Pardon the false alarm.

Thanks for all the work on this one @DaniGuardiola 🥳

I just cherry-picked this PR to the release/19.4 branch to get it included in the next release: 9586226